https://github.com/RobotsAndPencils/xcodes

・swift製

・homebrew(これもまあrubyだが)経由でインストール可能

という感じで、まあ問題なく動くのでこれでいこうと思う。

使い方

xcodes list

で適当に対象の一覧が出せて、適当にverを選んで

xcodes install 11.3.1

とかで、最後にPCのパスワードを入力してインストールが完了する。

使う時は、

xcodes select 11.3.1

とかをやっておくと、xcodeproj開いた時とかに開かれるようになる。

https://github.com/sassembla/Autoya/releases/tag/0.9.14

IEndPointを実装したクラスを作る + そのインスタンスを渡すフローがAutoya内に構築してあるので、めっちゃ使いやすい。

比例してOverridePointsに多量のメソッドが増えている。

https://qiita.com/tetsuhama/items/6a89a490ec7faeebc06f

Activityで表示するAppの限定化

https://qiita.com/hiroshido/items/a7899012d78b65a22021

コンテンツをツールごとに変える

https://www.lanches.co.jp/blog/10776

コールバックは取れるから、Twitterだったかどうかとかまではわかる。

まあわかるだけだなー、TweetIdとかはわからない。

Android

動くけど、ブロックしちゃうのが気に食わない。

http://nirasan.hatenablog.com/entry/2014/12/24/105737

TwitterAppが入っているかどうかがわかるとかいろいろある。

https://gist.github.com/ueno-yuhei/2892e9be68a567d4ca52

https://github.com/sassembla/LayouTaro

・Unityで扱えるUIを型で定義、生成し

・それを可変長引数に放り込むとレイアウトされる

というもの。

サンプルとして画像とテキスト、ボタンが使えるようにしてある。

動機

HTMLを書いて独自タグ定義すればいける、というのを目指したUUebViewは、あれはあれで一定の成功を収めている。

が、まーぶっちゃけ「Web専用の固定されたレイアウトを行う」ことに特化していて、自由度はない。

反面、ルールさえ書ければ独自のレイアウトができる、みたいな機構が欲しいというニーズは根強く存在していて、今回はこれを叶えたい。

・タグ定義ができて(LTElement)

・レイアウターを作成すれば

・独自タグで独自レイアウトができる

これが理想。で、かなりいい線まで、非常に小さいコードベースで行けたと思ってる。

文字だろうが画像だろうがボタンだろうが、所詮はTextとRectなので、それをレイアウトしたい、という比較的ベーシックな欲求も叶えられれば、

このタグはこういうレイアウトにしたい、必ず上に表示されて欲しい、ツールチップみたいにマウスオンしたら、、みたいなマニアックな要望まで、

LayouTaroは(しちめんどくさいレイアウトを書くことに人生を捧げるだけで)叶えてくれる。

Textとは、「連続する要素がレイアウト位置に応じて変形、改行される」もの。主に文字。

Rectとは、「要素がアトミックでレイアウトによる変形がない」もの。主に画像とか。

構成

LayouTaroアセットの全体的な構成は次の3層。

・レイアウトまでのフローをフレームワーク化したLayouTaro

・独自タグ(LTElement)

・LayouTaroで動かせるレイアウター

LayouTaroが提供するフローに則ると自作のタグを自作のレイアウターでレイアウトすることができるよ、という感じ。

右向き行単位での縦揃えと左下への改行を行う、という基礎的なレイアウト機能は、実装例を兼ねてBasicLayoutFunctionという名前で組み込み機能として定義されている。

読んでもらえばわかるが、レイアウトとはかなりファンキーだ。まあ、これはまだそれなりにかんたん。

独自のUIパーツを作った時に、それをどう並べるか、各要素が内容によって伸び縮みしたらどうなるか、

そういうのを解決していって欲しい。

使い方

1. 型の定義

    public enum LTElementType

    {

        Box,

        Image,

        Text,

        Button

    }

自分が足したいコンテンツの識別子(LTElementType)を LayouTaro/LayouTaroElements/LayoutElementType.cs に書く。

2. LTElementの定義

public class ButtonElement : LTElement, ILayoutableRect

{

    public override LTElementType GetLTElementType()

    {

        return LTElementType.Button;

    }

    public Image Image;

    public Action OnTapped;

    public static ButtonElement GO(Image image, Action onTapped)

    {

        // prefab名を固定してGOを作ってしまおう

        var prefabName = "LayouTaroPrefabs/Button";

        var res = Resources.Load(prefabName) as GameObject;

        var r = Instantiate(res).AddComponent<ButtonElement>();

        r.Image = image;

        r.OnTapped = onTapped;

        // このへんでレシーバセットする

        var button = r.GetComponent<Button>();

        button.onClick.AddListener(() => r.OnTapped());

        return r;

    }

    public Vector2 RectSize()

    {

        // ここで、最低でもこのサイズ、とか、ロード失敗したらこのサイズ、とかができる。

        var imageRect = this.GetComponent<RectTransform>().sizeDelta;

        return imageRect;

    }

}

UI要素として、LTElementを継承したクラスを定義する。LTElementはMonoBehaviourを継承しているので、このスクリプトはファイル名とクラス名を一致させる必要がある。

GetLTElementTypeで先ほど定義したLTElementTypeを返すコードを書く。

定義するUIパーツがRect(矩形)なのかText(文章)なのかで、追加で実装すべきインターフェースが決まる。

ここでは、画像を使うUIパーツを定義したいので、ILayoutableRectを持たせる。

で、このクラスをAddComponentした状態のGameObjectを返す関数を定義すると、あとが楽。

3. RootElementの定義

2と同様、LTRootElementを継承した型を作成する。

LTElementと異なるのは、GetLTElementsというLTElementのarrayを持たされること。

public class BoxElement : LTRootElement

{

    public override LTElementType GetLTElementType()

    {

        return LTElementType.Box;

    }

    public override LTElement[] GetLTElements()

    {

        return elements;

    }

    private LTElement[] elements;

    public Image BGImage;// 背景画像、9パッチにすると良さそう

    public static BoxElement GO(Image bg, params LTElement[] elements)

    {

        var prefabName = "LayouTaroPrefabs/Box";

        var res = Resources.Load(prefabName) as GameObject;

        var r = Instantiate(res).AddComponent<BoxElement>();

        r.BGImage = bg;

        r.elements = elements;

        return r;

    }

}

4. UIの生成とレイアウト

独自定義した要素を生成、Rootを親として子供要素をガンガン入れる。

        // データ構造を作る、自由に構造を書いていい。

        var box = BoxElement.GO(

            null,// bg画像

            () =>

            {

                Debug.Log("ルートがタップされた");

            },

            TextElement.GO("hannin is yasu! this is public problem! gooooooooooooood"),// テキスト

            ImageElement.GO(null),// 画像

            ButtonElement.GO(null, () => { Debug.Log("ボタンがタップされた"); })

        );

        // レイアウトに使うクラスを生成する

        var layouter = new MyLayouter();

        // コンテンツのサイズをセットする

        var size = new Vector2(200, 100);

        // レイアウトを行う

        var go = box.gameObject;

        go = LayouTaro.Layout<BoxElement>(

            canvas.transform,// レイアウトしたものを置く親のTransform

            size,// レイアウトするビューのサイズ。横幅はそのまま、縦に延びるのを想定している。

            go,// LTRootElement型を継承しているT型のComponentがセットされているGameObjectを指定する

            layouter// レイアウトに使用する操作法をセット

        );

こうして生成された、自由な順番 + 内容でLTElementを含んだboxと、自由にレイアウトを記述できるILayouterを拡張したMyLayouterのインスタンス、そして

コンテンツをレイアウトするためのサイズを用意する。

最終的に LayouTaro.Layout<LTRootElement型> メソッドを実行すると、LTRootElementを拡張した型のGameObjectの中身がレイアウトされる。

上のやつだと、

・幅200のコンテンツに、BoxElementを親として、子コンテンツとしてText(犯人はヤス)、Image(null)がレイアウトされる

という感じになる。

レイアウトコード

ILayouterを実装したクラスのメソッドがレイアウト時に自動的に呼ばれる。

そこで、自力で種類単位でのレイアウトをしてもよし、予め用意されているBasicLayoutFunctionsを利用することも可能。

ILayouterには次の2つのメソッドが定義されている。

Layout関数はLayouTaroのLayout関数から呼ばれる。 コンテンツのレイアウトをTypeEnumごとに事細かく描くことができる。

public void Layout(Vector2 viewSize, out float originX, out float originY, GameObject rootObject, LTRootElement rootElement, LTElement[] elements, ref float currentLineMaxHeight, ref List<RectTransform> lineContents)

UpdateValues関数はLayouTaroのRelayoutWithUpdate関数から呼ばれる。 レイアウト済みのオブジェクトに対し、任意の値をセットすることができる。

public void UpdateValues(LTElement[] elements, Dictionary<LTElementType, object> updateValues)

試しにLayouterを実装してみた場合の全体は以下のようになる。 ILayouterを継承している。

public class MyLayouter : ILayouter

{

    /*

        子要素をレイアウトし、親要素が余白ありでそれを包む。

    */

    public void Layout(Vector2 viewSize, out float originX, out float originY, GameObject rootObject, LTRootElement rootElement, LTElement[] elements, ref float currentLineMaxHeight, ref List<RectTransform> lineContents)

    {

        var OutsideSpacing = 10f;

        originX = 0f;

        originY = 0f;

        var originalViewWidth = viewSize.x;

        var viewWidth = viewSize.x - OutsideSpacing * 2;// 左右の余白分を引く

        // MyLayputはrootとしてboxがくる前提で作られている、という想定のサンプル

        var root = rootObject.GetComponent<BoxElement>();

        var rootTrans = root.GetComponent<RectTransform>();

        for (var i = 0; i < elements.Length; i++)

        {

            var element = elements[i];

            var currentElementRectTrans = element.GetComponent<RectTransform>();

            var restWidth = viewWidth - originX;

            lineContents.Add(currentElementRectTrans);

            var type = element.GetLTElementType();

            switch (type)

            {

                case LTElementType.Image:

                    var imageElement = (ImageElement)element;

                    BasicLayoutFunctions.RectLayout(

                        imageElement,

                        currentElementRectTrans,

                        imageElement.RectSize(),

                        ref originX,

                        ref originY,

                        ref restWidth,

                        ref currentLineMaxHeight,

                        ref lineContents

                    );

                    break;

                case LTElementType.Text:

                    var newTailTextElement = (TextElement)element;

                    var contentText = newTailTextElement.Text();

                    BasicLayoutFunctions.TextLayout(

                        newTailTextElement,

                        contentText,

                        currentElementRectTrans,

                        viewWidth,

                        ref originX,

                        ref originY,

                        ref restWidth,

                        ref currentLineMaxHeight,

                        ref lineContents

                    );

                    break;

                case LTElementType.Button:

                    var buttonElement = (ButtonElement)element;

                    BasicLayoutFunctions.RectLayout(

                        buttonElement,

                        currentElementRectTrans,

                        buttonElement.RectSize(),

                        ref originX,

                        ref originY,

                        ref restWidth,

                        ref currentLineMaxHeight,

                        ref lineContents

                    );

                    break;

                case LTElementType.Box:

                    throw new Exception("unsupported layout:" + type);// 子のレイヤーにBoxが来るのを許可しない。

                default:

                    Debug.LogError("unsupported element type:" + type);

                    break;

            }

        }

        // 最終行のレイアウトを行う

        BasicLayoutFunctions.LayoutLastLine(ref originY, currentLineMaxHeight, ref lineContents);

        // サイズを調整する

        rootTrans.sizeDelta = new Vector2(originalViewWidth, Mathf.Abs(originY) + OutsideSpacing * 2);// オリジナル幅で、高さに対して2倍分の余白を足す。

        // 子要素の余白分の移動

        foreach (var e in elements)

        {

            var rectTrans = e.GetComponent<RectTransform>();

            rectTrans.anchoredPosition = new Vector2(rectTrans.anchoredPosition.x + OutsideSpacing, rectTrans.anchoredPosition.y - OutsideSpacing);// ルートの下のエレメントの要素をスペース分移動する。yは-なので-する。

        }

    }

    public void UpdateValues(LTElement[] elements, Dictionary<LTElementType, object> updateValues)

    {

        foreach (var e in elements)

        {

            switch (e.GetLTElementType())

            {

                case LTElementType.Image:

                    var i = (ImageElement)e;

                    // get value from updateValues and cast to the type what you set.

                    var p = updateValues[LTElementType.Image] as Image;

                    i.Image = p;

                    break;

                case LTElementType.Text:

                    var t = (TextElement)e;

                    // get value from updateValues and cast to the type what you set.

                    var tVal = updateValues[LTElementType.Text] as string;

                    t.TextContent = tVal;

                    break;

                default:

                    break;

            }

        }

    }

}

実例

こんな感じのレイアウトができたりする。はい。

いい感じ。

https://blogs.unity3d.com/jp/2019/09/19/support-for-apple-sign-in/

記事で紹介されてるパッケージのURLはこれ

https://assetstore.unity.com/packages/tools/sign-in-with-apple-154202?_ga=2.99623134.1148277808.1584082182-434679709.1581905190

最終更新が2/14とかなんだけど、修正されてない。

ここで紹介する問題はすべてUnityが用意しているUnityクライアントSIWA用のObj-Cコードに由来する。

問題点は以下

・nonceを扱っていないのでリプレイアタックされ放題になる

・nonceを扱っていないので出元の確認ができない

・AuthorizationCodeを扱っていないので検証がしょぼい気がする(検証中)

nonceを扱ってないのの何が問題か

・おんなじデータをexprが切れる前に投げ放題

・サーバ側がJWTを検証する材料が不足する

ひとえに、せっかくSIWA自体の機構がnonceを使うことを推奨しているのに、それを使わないので脆弱になっている。

SIWAのnonce

iOS13以降に入っているASAuthorizationAppleIDProviderでは、リクエストの生成時にnonceパラメータをセットすることができる。

これは、任意の値をnonceパラメータにセットし、そのパラメータがリクエストの成果物に含まれることを意味する。

例えばサーバでnonce1を生成、クライアントがそれを受け取りnonce1をnonceパラメータにセットすると、Appleから返送されてくるデータにnonce=nonce1が入る。

これによって、クライアントがサーバへと認証データを送った際、サーバ側はnonceに何が含まれているかという情報で検証することが可能になる。

まーーーこれがないと、サーバ側は「jwtのフォーマット的には正しいが、それ以外に検証要素がない」という状態に陥る。

nonceの追加

で、Unityが提供しているSIWAライブラリにはnonceをセットする部分がゴッソリ抜け落ちているんで、足したものがこちら。

Autoya Thirdpary Authentication

https://github.com/sassembla/Autoya/blob/feature/signinwithapple/Assets/Autoya/ThirdPartyAuthentication/SignInWithApple/Plugins/iOS/SignInWithApple.m#L59

        request = [provider createRequest];

        [request setRequestedScopes: @[ASAuthorizationScopeEmail, ASAuthorizationScopeFullName]];

        // set nonce for verification.

        [request setNonce:nonce];

これでnonceがセットできる。C#側のコードからのセットまで当然可能になってる。

で、これでsignup/signin時にnonceをセットすると、Appleが返してくるidToken(JWT)のpayloadにnonceが入るようになる。

例えば db862182-d25b-44f7-ae26-8c11437c1d80 という値をnonceに入れてsignup/signinを行うと、次のようなJWT payloadが帰ってくる。太字のところがnonce。

{

  "iss": "https://appleid.apple.com",

  "aud": "com.kissaki.app”,

  "exp": 1584132002,

  "iat": 1584131402,

  "sub": “xxxxx.xxxxx”,

  "nonce": "db862182-d25b-44f7-ae26-8c11437c1d80",

  "c_hash": "VUbmqVL9jkYt5VpBCtWkhQ",

  "email": “xxxxx@x.x”,

  "email_verified": "true",

  "auth_time": 1584131402,

  "nonce_supported": true

}

んでーー、これを検証するnode.jsのコードはこんな感じになる。太文字のところがnonce関連。

事前にAUDIENCE_CLAIM(Appのidentifier)、

ID_TOKEN(検証したいidToken、クライアントでSIWAが成立したら出てくるやつ)、

NONCE(クライアントでSIWAのSignup/Signinをする際に入力したやつ) を入れておく。

verify.js

const AUDIENCE_CLAIM = "com.kissaki.app”;

const ID_TOKEN = “xxxxx.xxxxx.xxxxx”;

const NONCE = “xxxxx”;// nonce should be issed and recoded by the app-server and the client app should use it for SIWA signup/signin.

const jwt = require('jsonwebtoken')

const jwksClient = require('jwks-rsa');

var client = jwksClient({

  jwksUri: 'https://appleid.apple.com/auth/keys'

});

function getApplePublicKey(header, callback) {

  client.getSigningKey(header.kid, function (err, key) {

    var signingKey = key.publicKey || key.rsaPublicKey;

    callback(null, signingKey);

  });

}

jwt.verify(ID_TOKEN, getApplePublicKey, null, function (err, decoded) {

  if (err) {

    console.error("validation err:" + err);

    process.exit(1);

  }

  if (decoded.nonce !== NONCE) {

    console.error("unexpected nonce (nonce claim): ", decoded.nonce);

    process.exit(1);

  }

  if (decoded.iss !== "https://appleid.apple.com") {

    console.error("unexpected issuer (iss claim): ", decoded.iss);

    process.exit(1);

  }

  if (decoded.aud !== AUDIENCE_CLAIM) {

    console.error("unexpected audience (aud claim): ", decoded.aud);

    process.exit(1);

  }

  console.log("succeeded to validate Apple token: ", decoded);

});

検証に成功すると次のようなログが出る。

succeeded to validate Apple token: {

  iss: 'https://appleid.apple.com',

  aud: 'com.kissaki.app‘,

  exp: 1584139641,

  iat: 1584139041,

  sub: 'xxxxx',

  nonce: '8a12db08-1e5f-4bbf-83be-4220abb3c55d',

  c_hash: ‘xxxxx’,

  email: ‘x@x.x’,

  email_verified: 'true',

  auth_time: 1584139041,

  nonce_supported: true

}

検証に失敗する場合はその理由が出る。

注意して欲しいのは、上のコードはあくまで手元のnode.jsを使って検証してみよう的なホビーコードだってこと。

実際にはJWTに含まれているnonceについて、サーバ側でそのnonce値が正しいものか、すでに1度使われたものではないか、というのを確認する必要がある。

なので～上のコードとはかなり違ってくる。

で、nonceパラメータをサーバサイドが発行するごとにユニークに変化 + 記録すれば、

・既に使われたnonceが来たら殴れる

・検証の材料にできる

という、まあ、はい。普通ですね。

これでやっと、Androidの課金検証と同レベルの検証ができるようになった、、はず。

nonceには何を入れても(なんか長さ制限とかはRFCとかにあると思うが)いいはずなんで、リプレイアタックの防止と、JWT検証の助けにしようね～。

AuthorizationCode関連

Unityが配布しているSIWAのコードに入ってなかったのは、nonceだけではなく。

AuthorizationCode と呼ばれるパラメータもObj-C側のコードで無視されていた。

んでーーこれーー、なんかrefresh tokenとかが取得できると思ってるんだけど、設定が膨大なんでまだ確認できてない。

AppleのサーバにAuthorizationCodeを使って問い合わせて、200が帰ってくればOK～という認識なんだけど、途中。

危機感が出てきたら続きを書く。

昨今のAndroidの課金周りとかが壊滅的な改竄を受けてる(ので、なんかチート防止ツールの価値がより強固になってる)のがかなり残念という認識を持ってるんで、

や～～っぱ通信しましょうよー～～みたいなことを言い出す気がする。自分は。

参考

調べるにあたって、このへんを参考にした。

Apple

JWTのverifyの話 nonceはここでも紹介されてる。

https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user

Sign in with Apple を本番でやらかしをしないために考えてみた

最も参考にした記事。もっと読み込まないといけない。

https://nerocrux.hatenablog.com/entry/2019/12/11/163231

What the Heck is Sign In with Apple?

AuthorizationCodeをverifyするための設定の話を書いてくれてる。読んでる。

https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple

https://www.fast-system.jp/unity-deform-1-0-assets/

読んでみたとこ

JobSystemで動いている。で、計算は「頂点を目標点に動かす」という感じで動作している。

CPUだけを使った頂点移動で、まるごと全ての点を移動している。

これを応用するには、

・インデックスで点AからBの間はこの変形

みたいな応用をすると良さそう。indexの集合を作って集合ごとにIJobParallelForに放り込むとかそんな感じか。

https://github.com/sassembla/Chanquo

対応し途中のもの

・スロットルの概念があってもいい(N個をまとめて受ける)

・Jobまわりを綺麗にアレしたいができない

これらは途中。で、これら以外は対応できた。

結果

こんな感じの書き方ができるようになった。

var ch = Chan<T>.Make();

ch.Send(new T(){});

struct型Tを指定して、chの生成、chへとデータの送付。

goでの ch <- データ みたいな形。

受け取り側は複数パターンが使えて、

// start receiving data asynchronously.

ch.Receive(

    (T data, bool ok) => {

        // ok will become false when the channel is closed somewhere.

        // when ok is false, data is empty.

    }

);

1. select 文に対するcase data, ok := <- chのような扱い。

非同期で継続的な受け取り。これはv1と同じようなシグニチャになっている。と思ったけどそうでもないか。

誰かがchをCloseするとokがfalseな状態で飛んでくる。

// receive data until Chan<T> is closed.

yield return Channels.For<T>(

    T t =>

    {

    }

);

2. こちらはfor文での for data := range ch 相当。

Unityの場合はブロックせずに一定の位置で待つ、というのがasync汚染なしでは辛い(なんかいい手段ある？)という感じなので、

yield return と組み合わせる形にしている。

// wait first data then go through.

yield return Channels.WaitFirst<T>();

3. こちらは単純に <- ch と同じようなもの。

T型のデータがどこかから送信されると、yieldを抜ける。

goの場合はgoroutineでブロックをつくりまくっても全体には影響が及ばないのだが、

Unity C#の場合はブロックするとてきめんに詰む。

そのため、「その位置で待つ」という機能としてyield returnを使っている。

感想

より捨てやすく、なんとなーくUnityフレンドリーな書き方もできるようになった。

structが使えるのもよい。

https://noracle.jp/unity-no-debug/

この記事では、

・自前でUnityEngine.Debugを上書きして

・Conditional属性をつけることで、根こそぎ無効にできる

という手法と、その手法がなお及ばない部分がある、と言うことを示してくれている。

・using A=B とかやられてるやつは対処できない(ライブラリとかにめっちゃある)

ということがそれ。コードならいいけど、dllなら？ 詰むが？

そしてそれとは別に、まあ、自分はこっちの方が気になるんだけど、

・毎回誰かが同じ、Debug.Log*系のコードを書かないといけない

これなんの罰ゲームだよ。被ったりするしみんなが同じことを毎回やる必要ないでしょ。

そう、つまり不完全なのだよ。

完全な、デザインされた元栓が欲しいんだ。

こうであってほしい

・コンパイル時にUnityEngine.Debug.LogをConditionalで制御できるようにしてほしい

・そしたらコンパイル時にUnityEngine.Debug.Logを呼んでる箇所は、たとえdllの中でも消えてくれると思うし、

・例えばログのためのローカル変数とかもunused扱いになってコンパイルで消せると思うので

みたいな感じ。ユーザーが書けるC#レイヤーでこういう問題に挑ませるの悪手だと思う。

具体例を書こうか。

こういうコードがあったら、

foreach (var path in deleteTargetPaths)

{

    Directory.Delete(path, true);

    Debug.Log("folder deleted:" + path);

}

もし、Debug.LogがConditionalAttributeとかで実装してあれば、

foreach (var path in deleteTargetPaths)

{

    Directory.Delete(path, true);

}

コンパイル時にこうなったりするはずなんだよ。

するとどうだ、"folder deleted:" + path が関数ごと消えるでしょ。こうなれば関数がどうなってようと関係ないじゃん。幸せでは。

IL2CPP側はどうなっているのか

で、まあ、自分の中での結論は↑の通り、UnityEngine.DebugにConditionalつけといてよ、なのだが、

それはまあなんか言う機会を作って言えばいい話なので、なんならバグレポレベルだと思ってるしそれはそれとして。

今できることはなんだろうか。

例えば、IL2CPPへとコンパイルされた段階で、Debug.Log関数の元締めは世界で一個しかないはずだ。

だから、その関数をIL2CPP上から滅殺できる、みたいなマクロがもしラッパーとして定義されていれば、

その部分をいじることでマクロとしてDebug.Logを消し、Log関数に読み込まれている各種string化処理とかconcat処理とかも、

コンパイラが「お前これつかってないやんけ！！」パワーを発揮して滅殺してくれるのでは！？？？！？ という夢があった。

結論から書くとそれは夢だった。マクロなんかなかった。

IL2CPP世界のログの定義はこんな感じのところにある。

PROJECT/iOS/Classes/Native/Bulk_Assembly-CSharp_0.cpp

(行数に注目するとちょっとクスッとくると思う)

さあ、C# UnityEngine.Debug.Logが変換されて出てくるログの関数を探そう。

該当の関数はこれ。

// System.Void UnityEngine.Debug::Log(System.Object)

extern "C" IL2CPP_METHOD_ATTR void Debug_Log_m4051431634 (RuntimeObject * __this /* static, unused */, RuntimeObject * p0, const RuntimeMethod* method);

長えな。

mなんちゃらの数値は、Unityのバージョンに関連なく固定っぽい。特にビルド対象によって変動はしなかった。

そしてこの関数はIL2CPP化されたコードの上で使われてるはずなので、使用箇所を探してみる。

Debug_Log_m4051431634(NULL /*static, unused*/, _stringLiteral223888751, /*hidden argument*/NULL);

こんな感じに、そのままログ関数がコード上で使われている。

マクロとかでラップされてて、マクロを書き換えればあら不思議、なかったことに、、、！！ みたいな世界はこの世にはなかった。本当に残念だ。

ここで、「マクロで書かれてれば最悪でもIL2CPPレイヤーでなんとかできるのでは」という夢は霧散する。

IL2CPPでDebug.Logを書こう

最後に、IL2CPPで好きなようにログを書く、という、この世の果てで使えそうなデバッグ手法を紹介しておく。

IL2CPPで出力されたC++コードとは何か、っていうと、あれは、コンパイル結果だ。

断じて人間が何かを書き加えたり、変更を加えられる空間ではない。

で、まあ、

Debug_Log_m4051431634(NULL /*static, unused*/, _stringLiteral223888751, /*hidden argument*/NULL);

とかのコードでは、

_stringLiteral223888751

というポインタにIL2CPP string型みたいなのがあって、そこにC#で書いたC# stringが置かれている。

(実際にはバカでっかい文字列置き場があって、そこにすべての文言が連続する形でキュッと収められている。)

さて、そのIL2CPP string、自力で作ることはできるのか。

できる。

IL2CPP_RUNTIME_CLASS_INIT(Debug_t3317548046_il2cpp_TypeInfo_var);

String_t* a = il2cpp_codegen_string_new_wrapper("comment here!!");

Debug_Log_m4051431634(NULL, (RuntimeObject *)a, NULL);

こんなふうにすれば、comment here!! っていう表示がXcodeとかに出る。

便利でっしゃろ。

IL2CPP世界ではXcodeのbreak pointを置くことでもちろんいい感じにステップ実行できるんだけど、

ポインタのラッパーやラッパーのラッパーがあるせいで、さてここにどうやってジャンプしてきたんだろう、みたいなスタック情報がかき消えているケースが多い。

つまり上から下は見やすいんだけど、

下から上が超絶に見えない。

となると最後の手段はログでしょって感じで、上記のコードが使える。

前提としては、

#include "codegen/il2cpp-codegen.h"

をincludeしている必要があるが、IL2CPPで作成されたコードにはだいたいincludeされてる。

感想

ここまで読まれた人がいたら、ついででいいので読んでおいてほしい。

自分はこう思っている。

・Debug.Logを無効化する方法はいろいろあるが、いまだに完全なものはない。完全なものが欲しい。誰が書いたどんなコードにも適応できる、完全なものが。

・まあ別にstring concatとかToStringとか重たい関数をDebug.Log()のかっこの中で実行してGCがでるくらいいいじゃん、という発想は別にアリだと思っている。

・Debug.Logが一つでもコードに残っているのは悪だ、どんどん消すべき！みたいなのには別に同意しない。

・そんなのは書いたやつの自由だし、なんで製品版ビルドなのにログで損をするんだよという感じ。

・そして、それらとは関係なく、この文脈においてDebug.Logをユーザーに上書きさせることはやはり狂っている。

以上だ。

はい。

https://github.com/sassembla/A-npanRemote

名前にハイフンが使えて大満足。Unity内でも問題なかった。

由来はARです。イニシャルが。

原因

Unity標準のARKitRemoteの、接続をする、ボタンを押す、動作する、、、みたいなのが本当に最悪の体験だった。

なんか切れたり落ちたりするし、接続自体に失敗するみたいなのまである。これではダメだ。こんなダメな体験で人生を無駄にしてはいけない。

ということで目指したのは以下

・エディタ上でARKitを使うコードを書いたら自動的にARKitサーバが立ち上がるようにする

・ARKitを動かすiOSアプリ側からいつでも、何回でも接続、再接続できる

・無線で接続できる。

構造

まず、iOS ARKit実行機からはUnity Editorに接続することにした。

これはまあ、エディタで動いてる時しか使わんでしょみたいな感じ。

接続にはWebSocketを使う。そのため、iOS側にはWSクライアント、エディタにはWSサーバが立つ。

概念的に書くとこんな感じ

iOS ARkit -ws-> Unity Editor

WSサーバは結構軽量なんで、ユーザーがエディタのPlayを押したら起動、Stopを押したら落とす、みたいな感じにした。

次にPlay中にARKitを使うところまできたら &&  iOS ARKitからのインプットが来ていたら、自動的にiOS ARKitのインプットをPlay中のアプリに流し込みたかった。

で、エディタとPlay中のアプリの接続には、やっぱりWebSocketを使った。

概念的に書くとこんな感じ2

iOS ARkit -ws-> Unity Editor <-ws- Player

面白くなってきやがったぜ。

最終的なデータフローとしては、上記を実装した上で、iOS -> Editorで中継してPlayerに流し込む という単純なものになっている。

この構造ならiOS側が切断しようがPlayer側が切断しようが、どちらかが復帰したタイミングでデータを流せる。

展望

現状はただARKitについて動くだけなんで、今後はOculus Questの視界とかコントローラとかをUnity Editorにほうり込めるようにする。

WebSocketサーバで自前のやつがあったんだけど権利の関係でちょっと改修が必要で、現在はFleckというMITライセンスのライブラリに依存している。

MSの用意してるWebSocketサーバのAPI実装はリクエストヘッダ付きのモバイルからの通信に対してちゃんと動作しなかったので無視する。出来が悪い。

みんなSocketを使って実装してるぞ。ハイレベルなAPIなんか使い物にならないから使われてないぞ。俺も使ってないが。君はどうだ。

https://developer.android.com/studio#downloads

間違ってもAndroid Studioとか要らない。

DLしたsdkは、zipファイル名をフォルダ名にして、Applicationsフォルダ以下においとく。この場合は、sdk-tools-darwin-4333796。

で、設置が終わったら、Unity > Preferences > External Tools でsdk -> browse とやって、toolsフォルダを指すと設定が完了する。

SDK周りの設定

えーっと、AndroidのSDKは、インストールしただけだと何も入っていない状態なので、特定のバージョンのsdkをインストールする。

sdkmanagerをコマンドラインで動かせば終わりなんだけど、

サクッと動かすためにはJAVA_HOMEの環境変数設定が必須。いやなんか回避できるんだろうけど、今時そういうのダサい、、、はい。

Unityに含まれるjdkのパスを指定する

export JAVA_HOME=/Applications/Unity2018.3.11f1/PlaybackEngines/AndroidPlayer/Tools/OpenJDK/MacOS/

sdkmanagerを起動、欲しいバージョンのsdkをインストールする。

/Applications/sdk-tools-darwin-4333796/tools/bin/sdkmanager --update

/Applications/sdk-tools-darwin-4333796/tools/bin/sdkmanager "platform-tools" build-tools;28.0.2

万が一、億が一、jdkのインストールが必要な場合、

brew cask install homebrew/cask-versions/adoptopenjdk8

とかで、比較的人権を保った状態でJDKを入れられる。まだ捨てやすい。

ndkインストール

Unity AndroidでIL2CPPを使ったアプリを作るには、ndkが必要。

Unity > Preferences > External Tools のとこのndkのDownloadボタンがあるので、dlしたらApplications直下に置く。

設置し終わったら、Unity > Preferences > External Tools の ndk -> browse で、設置したフォルダを指すとOK。

最終的にはこんな感じになればいい。

以上。忘れたいので書く。

https://github.com/sassembla/Autoya/blob/master/Autoya.AssetBundles.unitypackage

Autoyaはログインから課金まですべからく俺が欲しい機能がいっぱい入っていて、まあ、薄いけどでかい。

そんなにたくさんの機能いらないよ！というのは正直わかる。

なので、まあ、Autoyaは実は複数の機能単位でのモジュールと、それを中央制御するレイヤー(Backyard)でできている。

今回はそれらのモジュールのうち、AssetBundleに関わるものを抜粋したよ、という話。

Autoya AssetBundle Module

ABを生成する部分は含んでいないが、

ABの情報一覧を取得する機構、

AB情報を使って取り出したいAssetを依存関係とか全部みてなんとかする機構、

ABの一覧を更新する機構、

などが入っている。

使い方

1.この世のどこかでABとABListを作ります

2.App内でABListを取得します

3.App内でABに含まれているAssetをロードします

以上！ Unloadとかもあるよ。

サンプル

https://github.com/sassembla/Autoya/blob/master/Assets/Packager/AssetBundles/AssetBundlesLoadSample.cs

    IEnumerator Start()

    {

        var LIST_DOWNLOAD_URL = "https://raw.githubusercontent.com/sassembla/Autoya/master/AssetBundles/main_assets/OSX/1.0.0/main_assets.json";

        var ASSET_NAME = "Assets/AutoyaTests/RuntimeData/AssetBundles/MainResources/textureName.png";

        // Download AssetBundle List from web.

        var listDownloader = new AssetBundleListDownloader();

        AssetBundleList list = null;

        var cor = listDownloader.DownloadAssetBundleList(

            LIST_DOWNLOAD_URL,

            (url, newList) =>

            {

                list = newList;

            },

            (code, reason, status) =>

            {

                Debug.LogError("list download error, code:" + code + " reason:" + reason);

            }

        );

        while (cor.MoveNext())

        {

            yield return null;

        }

        // Load Asset from your AssetBundle.

        var loader = new AssetBundleLoader(

            bundleName =>

            {

                var path = "https://raw.githubusercontent.com/sassembla/Autoya/master/AssetBundles/" +

                    list.identity + "/" +

                    list.target + "/" +

                    list.version + "/";

                return path;

            }

        );

        // set list to AssetBundleLoader.

        loader.UpdateAssetBundleList(list);

        var loadCor = loader.LoadAsset<Texture2D>(

            ASSET_NAME,

            (name, tex) =>

            {

                Debug.Log("asset loaded! tex:" + tex);

            },

            (name, error, reason, status) =>

            {

                Debug.LogError("asset load failed. error:" + error + " reason:" + reason);

            }

        );

        while (loadCor.MoveNext())

        {

            yield return null;

        }

    }

MonoBehaviourのStartメソッドを使って、

ABListダウンローダーの初期化 -> 

ABListのダウンロード -> 

ABローダーの初期化 -> 

ローダーへのABListのセット -> 

ローダーで欲しいAsset名、型を指定して、データをロード

と、こういう感じでできる。

ABListの作り方

これはまだちょっとまどろっこしい。

Autoya+AssetGraphパッケージには、ABListのジェネレータも入っているが、その部分はAssetBundle.unitypackageには入っていない。

なので、次のフォルダをゴソッとgithubからダウンロードして、ABを作成したいプロジェクトに含む必要がある。

https://github.com/sassembla/Autoya/tree/master/Assets/Editor

中にはAssetGraphとAssetBundleListGeneratorのコードが入っている。

この状態でAssetGraphを起動し、適当にABを作るグラフを組み立ててビルドを行うと、プロジェクトフォルダにAssetBundlesフォルダが勝手に作られ、ABが生成され、

自動的にABListが生成される。

一度AssetGraphでビルドしたら、ABListにはバージョンという値が振られる。

バージョン値は、Unity上で Window > Autoya > AssetBundle List Version Editor というので変えられる。

変えた後でAssetGraphのグラフをビルドすると、そのverのABとかABListが出力される。

生成されたABが入っているフォルダを、どこか、、github上とかにでも置くと、物事が解決できるぞ。

やばくなったらCDNとかでググって。

https://docs.unity3d.com/ScriptReference/WebCamTexture-ctor.html

https://docs.unity3d.com/ScriptReference/WebCamDevice.htmlnew 

In your Repro project you selecting last front facing device from a WebCamTexture.devices with an assumption that it will be correct one, but it is not valid with new Camera kind introduced.

・UnityのあるバージョンからiPhone/iPadのデプスカメラに対応したんだよ

・そんでそのぶんのカメラが増えてる

・現状のお前のアプリはfrontFacing かつ lastで選んでるから、Depthカメラを引いたんだよ

という回答だった。

いや、お前、それ、今まで一個しかなかったfront facing cameraを、isFrontFacingで検索してる今までのアプリ全滅するぞ、後方互換性破壊してるやんけ

と思ったが、ふーーーんなるほどー＝＝＝～～～という感じで納得した。

納得いかないけど、旧来のアプリは大体死ぬが、破壊的変更ではあるが、

・front facing

・kind 

この2つを組み合わせてチェックする必要がある。

kind作るならカメラ一覧取得するときにGetDepthCameraとか作りなさいよという気持ちがMaxになりそうになるんだけど、

まーーーーーうーーーーーーーーーん、、、、ギリギリのギリギリで許す。

総評

互換性は破壊されている。俺は許すが俺の魂が赦すかな？！

https://github.com/sassembla/CO2

正しいモチベーション

前提としてAndroidのlibraryをビルドするには、結構なサイズのソフトが必要。

特にAndroidStudioが捨てやすさという意味で最悪。

さらにgradleとかでビルドする際に、依存関係のDLとかに膨大な時間とディスクスペースを使う。本当にクソ。

なので、DockerでJavaとかの入れ物ごと作って捨てる。

これでよし。

使い方

1.モジュールプロジェクトをjavaとかkotlinとかで書いて、projectフォルダに放り込む

2.build.sh モジュール名 でビルド。

ね、簡単でしょう？

https://github.com/sassembla/toriki

インストール

リリースがあるのでそこからUnityPackageを使ってインストールできる。

https://github.com/sassembla/toriki/releases/tag/0.9.0

使い方

1.TwitterSetting.cs にconsumerKeyとかconsumerSecretを書く。

https://github.com/sassembla/toriki/blob/master/Assets/Toriki/Scripts/TwitterSettings.cs

        static TwitterSettings()

        {

            ConsumerKey = string.Empty;

            ConsumerSecret = string.Empty;

Runtimeにあるコードで、torikiの初期化を行う際に自動的にロードされる。

Resourcesとかにキーを暗号化しておいて、ここで復号化すると良い。

2.初期化とAPI

https://github.com/sassembla/toriki/blob/master/Assets/_Sample/Login/Login.cs

        TwitterAPI.InitWithLogin(

            (nickname, token, secret) =>

            {

                // show user info API example.

                TwitterAPI.Get(

                    "https://api.twitter.com/1.1/users/show.json",

                    new SortedDictionary<string, string>

                    {

                        {"screen_name", "toru_inoue"}

                    },

                    result =>

                    {

                        Debug.Log("show result:" + result);

                    },

                    (code, errors) =>

                    {

                        Debug.Log("show code:" + code);

                    }

                );

                // tweet API example.

                TwitterAPI.Post(

                    "https://api.twitter.com/1.1/statuses/update.json",

                    new SortedDictionary<string, string>

                    {

                        {"status", "Love Toriki. "}

                    },

                    result =>

                    {

                        Debug.Log("update result:" + result);

                    },

                    (code, errors) =>

                    {

                        Debug.Log("update code:" + code);

                    }

                );

            },

            (errorCode, message) =>

            {

                Debug.Log("login error:" + errorCode + " message:" + message);

            }

        );

Init、 Loginの順に実行する。

ログアウトはない。

(TwitterKitではアプリ側に通信セッションを保存したりしていたんだけどその辺が多大な問題を起こしていた上に、別にいらないのでいらない。 だから消した。)

APIは、TwitterAPI.Get/Postとか書いて、TwitterのAPI Referenceに書いてあるようなパラメータを入れれば使える。

3.APIだけを使う

Loginで得られるaccessToken、secretがあれば、ログイン処理をいちいち挟まずにAPIを使うことができる。

https://github.com/sassembla/toriki/blob/master/Assets/_Sample/APIAccess/APIAccess.cs

        TwitterAPI.InitWithToken("ACCESS_TOKEN", "ACCESS_SECRET");

        TwitterAPI.Get(

            "https://api.twitter.com/1.1/users/show.json",

            new SortedDictionary<string, string>

            {

                {"screen_name", "toru_inoue"}

            },

            result =>

            {

                Debug.Log("show result:" + result);

            },

            (code, errors) =>

            {

                Debug.Log("show code:" + code);

            }

        );

InitWithToken とか。以上。

https://meetup.unity3d.jp/jp/events/1034

特徴

以前よりは軽量、高速になった。

Upgradable Shaders(https://github.com/Unity-Technologies/ScriptableRenderPipeline/wiki/Lightweight-Render-Pipeline#upgradable-shaders) に対応表がある。

SRP(ScriptableRendererPipeline)で実装されているため、カスタムシェーダでの面白表現とかがやりやすくなっている。

最近のバッチング

1マテリアルにつき、コンスタントバッファ作成 -> アップ -> 描画

ダイナミックバッチングでマテリアルごとにオブジェクトを結合、、！ってやってたんだけど、

ポリゴンが増えてきたんでバッチングはオフな方が効率が良くなってきた。

-> 代わりにInstancingを使おう。

SRPでは

UnityPerMaterial という属性で要素をUnityに登録する必要がある(キーワード)

するとSRPBatchingが発生する。

SRP勉強せんとな。

IRenderSetupを継承で云々とか。

俺はUVスクロールがしたかっただけなんだ

作っていくうちにガンガン高まっていく人見てると良い良いって感じになってくる

https://qiita.com/tkyaji/items/be7db0b419ce27c2a184

パッケージインストール

Window > Package Manager > Advancedボタンをクリックしてpreviewを選択 > previewを検索してインストール

インストールが完了するまで待つ。完了するとTinyメニューがでる。

サンプルプロジェクトの収集

Tiny > Import Samples でサンプルを収集、TinySamples/*/*.utproject ファイルを開いてPlay実行すると、ブラウザが開いてゲームが遊べる。

ログ

typescript内で普通にconsole.logが使える。これUnityEditorに返せると見やすいか？ そうでもないか。

今の所はTSなので、何か知りたいことがあったらログを書く -> ブラウザで実行

TinyでのEntityとは

Assetsウィンドウがこんな感じ。

エンティティの縛りをもってシーンの扱いとしてるっぽい。

起動時はBootstrapのシーンになっている。

基本動作

ComponentSystemというクラスと、OnUpdate : void みたいな関数があって、

その関数内でthis.world.forEach([エンティティ定義 x n]){

エンティティの調整

}

とやることで、エンティティの動作をいい感じにできる。

作って見たいもの

ミニゲーム、マリオみたいなやつ。

http://tips.hecomi.com/entry/2018/12/23/200817

Boid、Simulation

他のすべてのBoidの位置を見たりして動くBoidと、

それらを生成するSimulationという組み合わせ。

ここから、ECSに向けて分解していく。

entityを導入

パッケージマネージャーから導入。

BoidのECS対応

Boid、中では

・加速度、位置などのパラメータがある

・関数でそれらの中に値をセットする

ということをやっていて、

これを、

パラメータ -> エンティティ化

関数 -> システム化

ということをやっていく。

動きのバリエーションとしては、

・壁に近づいたら云々

・向きとか速度を云々

・他の個体と近づく離れるを云々

する。

パラメータの分解粒度については、

・各種システムが必要な情報をグルーピングしてくるときに本当に必要な最小の粒度で分解した方が良い

ということなので、

まずは最小粒度でエンティティ化してみよう。

コンポーネントの作成

コンポーネント = ECSで扱う型情報の定義、みたいな印象。

IComponentDataを継承したstructを定義し、内部にUnity.Mathematics に定義されている型(float3とか)を保持する。

float3は、3つのfloatが入っている型。

起動クラスの作成

ECSの関連性を起動する()ような処理を書く。

・コンポーネントの定義

・デフォルトのWorldからEntityManagerを取得

・アーキタイプと呼ばれるものをmanagerにセット

・レンダラの生成

・エンティティの生成、コンポーネントの追加

コンポーネントの定義

public struct Velocity : IComponentData

{

    public float3 Value;

}

public struct Acceleration : IComponentData

{

    public float3 Value;

}

IComponentDataを継承した型を生成しておく。

この型をエンティティにセットすることで、エンティティに対して任意の値を持たせることができるようになる。

デフォルトのWorldからEntityManagerを取得

Worldは自分で生成することもできる。

var manager = World.Active.GetOrCreateManager<EntityManager>();

このmanagerに対して、レンダラやアーキタイプをセットしていく。

アーキタイプと呼ばれるものをmanagerにセット

var archetype = manager.CreateArchetype(

            typeof(Position),

            typeof(Rotation),

            typeof(Scale),

            typeof(Velocity),

            typeof(Acceleration),

            typeof(MeshInstanceRenderer));

managerに対して、用意したComponentをセットしてく。

Position、Rotation、Scale、MeshInstanceRendererはUnityが用意してくれているものを使用、

Velocity、Accelerationはさっき書いたものをセットする。

こうすることで、archetypeを生成できる。

archetypeはComponentの型を列挙したデータを含んでいるインスタンス。

レンダラの生成

        var renderer = new MeshInstanceRenderer

        {

            castShadows = ShadowCastingMode.On,

            receiveShadows = true,

            mesh = mesh,

            material = material

        };

エンティティに対して描画時に使用する機構を生成しておく。

このrendererはあとでエンティティを生成する時にセットする。

エンティティの生成、コンポーネントの追加

            var entity = manager.CreateEntity(archetype);

            manager.SetComponentData(entity, new Position { Value = random.NextFloat3(1f) });

            manager.SetComponentData(entity, new Rotation { Value = quaternion.identity });

            manager.SetComponentData(entity, new Scale { Value = new float3(boidScale.x, boidScale.y, boidScale.z) });

            manager.SetComponentData(entity, new Velocity { Value = random.NextFloat3Direction() * param.initSpeed });

            manager.SetComponentData(entity, new Acceleration { Value = float3.zero });

            manager.SetSharedComponentData(entity, renderer);

managerに対して、archetypeを渡すことでエンティティを生成する。

こうすることで、これらのコンポーネントを持ったEntityが生成される。

で、entityのそれぞれのコンポーネントに対してデータをセットすることができる。

最終的にentityに対してrendererをセットすると完了で、動き出す。

ここまでで、エンティティの生成は完了。

次に、これらのエンティティを動かす仕掛け(System)について考える。

エンティティを動かす

ComponentSystemを生成する。

・データ型をどこかに定義(外部でもいいはず)

・ComponentSystem型を継承した型を生成、データ型をクラス内のフィールドにインジェクト

・OnUpdate関数を書く

データ型をどこかに定義(外部でもいいはず)

こんな感じの型を作る。

    struct Data

    {

        public readonly int Length;

        public ComponentDataArray<Position> positions;

        [WriteOnly] public ComponentDataArray<Rotation> rotations;

        public ComponentDataArray<Velocity> velocities;

        public ComponentDataArray<Acceleration> accelerations;

    }

Lengthには、自動的に「何個のEntityがあるか」が入る。つまりこの数分だけエンティティがある、という情報を取得できる。

positionとかがarrayになっていて、「すべてのエンティティのpositon」が入っているアレイになっている。すごい。

ComponentSystem型を継承した型を生成、データ型をクラス内のフィールドにインジェクト

public class WallSystem : ComponentSystem

{

    struct Data

    {

        public readonly int Length;

        [ReadOnly] public ComponentDataArray<Position> positions;

        public ComponentDataArray<Acceleration> accelerations;

    }

    [Inject] Data data;

    protected override void OnUpdate()

    {

.....

        for (int i = 0; i < data.Length; ++i)

        {

            data.accelerations[i] = new Acceleration { Value = accel };

        }

    }

}

OnUpdateが毎フレーム実行される。

Data型をInjectアトリビュートをつけて定義しているが、このインスタンスに対して自動的にエンティティが入る。

で、MoveとWallをセットすることで、移動と壁接近の処理を実現できる。

これらのComponentSystemを継承した型は、自動的にデフォルトのWorldに組み込まれる。

ここまでで壁接近と移動に関してのシステムができた。

で、その実行順の制御をいまのところはMoveSystemにattributeで

[UpdateAfter(typeof(WallSystem))]

とかやって行う。

ここからは、一つのエンティティから別のエンティティを参照して、群(Boid)っぽい挙動をさせる。

他の個体と近づく離れるを云々 の部分。

この場合、一つのエンティティから、ほかの(近所の)エンティティを、配列として扱うことになる。

配列をエンティティ内で扱う

データ型を定義する。

[InternalBufferCapacity(8)]

public struct NeighborsEntityBuffer : IBufferElementData

{

    public Entity Value;

}

IBufferElementDataを継承したコンポーネントを用意する。これで配列が扱える。

今まではIComponentData。

Entityを値として持つ。(配列として扱われる。)

アトリビュート InternalBufferCapacity はIBufferElementDataに対してセットする。

この数値を超えた場合はデータがC#のヒープにいってしまって遅くなるっぽい。

アーキタイプにNeighborsEntityBuffer型を足す。

        var archetype = manager.CreateArchetype(

            typeof(Position),

            typeof(Rotation),

            typeof(Scale),

            typeof(Velocity),

            typeof(Acceleration),

            typeof(MeshInstanceRenderer),

            typeof(NeighborsEntityBuffer)

        );

NeighborsEntityBuffer 型に関しては、CreateEntity時にデータをセットするような要素がないのでこのまま。

IBufferElementDataを継承した型の中身は、自動的に配列として扱われる。

この場合は、Entity型のアレイになる。

Bufferからデータを取り出す場合、Reinterpret<バッファに含まれている型> で、型のアレイが取り出せる。

            /*

                neighborsから一つを取り出す。ここでNeighborsEntityBufferの中身はEntityだけなので、

                Reinterpret<型>で指定するとEntityのアレイが手に入る。

            */

            var neighbors = data.neighbors[i].Reinterpret<Entity>();

これで、neighborsは DynamicBuffer<Entity> 型、Entityのアレイになる。

で、エンティティからPositionなどの一パラメータを取得するには、 EntityManager.GetComponentData<Position>(対象のエンティティ) とかやる。

このほかにAlignment(整列)とCohesion(結束)のSystemを作る。

順番付け

この時点で複数のシステムがあって、順番問題が出てくる。

別に複数のシステムに分けなくてもいいはずなんで、まとめてもいいんだけど、ここでは